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DETOMA:  Good  afternoon.  Basically,  the  issues  that  you  will  find  on  GNSS  interoperability  are:  signal 
spectrum  and  signal  structure;  reference  frames,  space,  and  time;  and  other  issues  that  will  come  up 
during  the  discussion. 
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So  first  of  all,  I  would  like  to  introduce  the  panel.  On  the  panel  we  have  Wlodek  Lewandowski  from 
BIPM;  Jens  Hammesfahr  from  DLR,  Germany;  Dr.  Nicholas  Koshelyaevsky  from  the  Institute  of 
Metrology  for  Time  and  Space,  Russia;  Dennis  McCarthy  from  the  USNO;  Ron  Beard  from  NRL;  Dr. 
Powell  from  the  Aerospace  Corporation;  Dr.  Hegarty  from  the  MITRE  Corporation;  Hugo  Fruehauf  from 
FEI-Zyfer  Corporation;  Bill  Klepczynski  from  the  Department  of  State;  and  myself. 

To  start  the  discussion,  I  have  asked  all  the  panelists,  as  an  introduction,  just  to  introduce  their  ideas  on 
interoperability.  We  will  start  with  Hugo  and  proceed  in  sequence. 

FRUEHAUF:  Good  afternoon,  ladies  and  gentlemen.  What  we  have  right  now  in  the  GPS/ 
GAFIFEO/GFONASS  area  are  the  blue  and  black  signals.  I  thought  we  would  start  with  a  chart  that 
would  put  everyone  on  the  same  frame  of  what  is  happening  here  in  the  future. 


GPS,  Galileo,  and  Glonass  Signals 


L2-Band  (MHz) 


LI -Band  (MHz) 


15J59 

11563 


WAAS,  EGNOS,  MSAS, 
SNAS  -  generated 
LI -C/A  Look-alike 


1610 


Black  and 
Blue  Signals 
Exist 


# 


GAL-LIp 


C-Band  (MHz) 


You  have  the  FI  band,  C/A,  and  P.  You  have  a  GFONASS  FDMA  system,  which  is  in  the  blue,  with 
their  equivalents  C/A  and  P.  Then  we  have  what  I  call  the  FI -C/A  look-alike,  which  comes  from  the 
WAAS,  EGNOS,  and  MSAS  systems.  As  you  know,  this  is  a  transmission  of  the  differential  corrections 
to  the  user  with  the  FI -C/A  look-alike  signal. 

And  then  on  the  F-2,  you  have  the  American,  of  course,  P-code  and  the  Russian  GFONASS  P. 

What  is  coming  up  in  the  future  is  a  clear  acquisition  signal  F2,  and  of  course  you  realize  that  that  is  in 
order  to  give  an  instantaneous  ionospheric  resolution  in  the  clear,  because  the  user  in  the  future  can  then 
do  a  code  comparison  between  FI  C/A  and  F2  C/A  to  accomplish  the  same  thing  that  was,  as  of  now, 
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only  accomplished  by  the  military  P-code  that  compares  P  to  P.  This  is  to  support  the  civil  aviation 
community. 

Then  an  L5  will  be  added,  also  to  support  the  civil  aviation,  for  integrity  and  an  additional  capability  for 
WAAS  and  all  of  its  tentacles.  Then  the  infamous  M-code  will  be  put  in  between  the  same  spectrum,  of 
course,  but  on  both  sides  of  the  C/A  signal,  both  on  LI  and  L2.  Then  the  Galileo  signal  is  in  green,  first 
Galileo  E5  will  be  superimposed  on  the  GPS  L5.  And  separate,  as  you  know,  of  course,  is  that  you  do  the 
coding  structures  with  spectral  densities  on  the  edges,  plus  you  use  different  modulation  techniques  in 
order  to  get  the  maximum  amount  of  isolation  between  signals  operating  the  same  bandwidth. 

And  then  the  Galileo  E5b,  another  signal  just  on  the  other  side  of  the  GPS  L2,  which  will  be  Galileo  E6, 
again  structured  in  such  a  way  that  interference  between  the  signals  is  minimized. 

Then  over  the  LI  GPS  signal,  you  will  have  again  a  structured  El  and  E2,  again  separated  properly  with 
code  structures  and  modulation  techniques.  And  the  C-band  frequency  which  was  planned  has  recently 
been  cancelled.  So  this  area  is  gone  mainly,  probably  because  of  the  cost  involved.  It  is  very  difficult  to 
make  a  receiver  now  that  is  C-band  and  make  it  as  cheap  as  the  receivers  that  can  be  made  in  the  bands 
that  we  spoke  of. 

So  in  general,  then,  it  is  quite  a  challenge  and  an  opportunity  for  the  commercial  sector  to  be  able  to  pick 
up  all  the  commercial  signals  that  will  be  integrated  in  the  receiver,  not  only  WAAS,  EGNOS,  MSAS, 
which  are  the  differential  correction  issues,  but  also  these  additional  signals.  So  the  future’s  commercial 
receiver  will  be  robust.  And,  of  course,  the  military  has  the  additional  challenge  of  its  existing  SAASM 
technology  to  be  updated  to  M-code  and  all  of  these  other  signals.  And,  of  course,  a  receiver  will  then 
have  a  huge  capability  to  sort  out  lots  of  signals  and  it  is  going  to  be  the  software  man’s  game  to  make  the 
best  receiver  on  the  planet. 

DETOMA:  Thank  you  very  much,  Hugo.  Now  the  next  speaker  will  be  Ron  Beard  from  NRL. 

BEARD:  Thank  you,  Ed.  When  Ed  asked  me  to  be  on  this  panel  about  interoperability,  I  thought  back 
about  the  various  forms  of  interoperability  I  have  been  engaged  in.  I  think  I  started  working  on 
interoperability  between  systems  back  in  the  1980s  at  some  point,  because  there  are  many  dimensions  to 
interoperability;  and  instead  of  putting  them  all  on  one  slide,  I  thought  it  might  be  better  to  simply 
introduced  the  concept  than  really  go  through  a  slide.  I  think  Hugo  did  a  nice  presentation  on  the  signal’s 
interfaces  between  these  various  systems.  But  there  are  also  the  interfaces  of  the  reference  systems  and 
the  usability  of  these  within  the  different  systems  from  different  user  groups  that  cause  additional 
problems. 

But  the  first  form  of  interoperability  that  I  became  engaged  with  was  looking  at  military  timing  signals  in 
a  NATO  context.  This  is  where  you  are  thinking  of  a  French  airplane  landing  on  German  airfield 
serviced  by  English  servicemen  with  U.S.  equipment.  There  you  are  talking  about  a  multiplicity  of 
interfaces  that  have  to  fit  together  and  how  the  timing  would  be  used  to  synchronize  a  variety  of  these 
military  systems  in  that  context  and  then  a  larger  context  becomes  even  more  complex. 

A  lot  of  those  interfaces  are  still  not  really  standardized  or  worked  out  as  to  how  not  just  satellite  systems 
fit  together,  but  how  the  systems  actually  talk  together  through  the  various  interfaces.  I  think  the  U.S.  is 
just  as  culpable,  guilty  as  anyone  as  to  defining  standardized  timing  interfaces  and  procedures  for  using 
these  different  systems  to  a  common  time.  Also,  the  common  time  is  another  problem  as  to  what 
realization  of  time  you  are  using  in  these  different  systems. 

That  brings  me  to  one  of  my  latest  adventures  in  interoperability,  which  is  looking  at  the  future  of  the 
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UTC  timescale  that  I  am  involved  in  with  the  ITU-R.  The  question  before  the  ITU-R  is  the  usability  of 
the  UTC  timescales,  in  particular  the  fact  that  it  is  discontinuous  and  has  leap  seconds.  In  the  working 
group  I  am  involved  with,  we  have  been  working  for  about  the  past  4  or  5  years  trying  to  determine  the 
usability,  the  limits  of  performance,  the  impact  of  continuous  or  discontinuous,  how  that  affects  all  these 
different  communities.  It  gets  very  involved  and  can  get  quite  emotional  in  some  cases,  because  of  the 
idea  of  having  a  discontinuous  reference  common  time  for  the  variety  of  systems  that  do  not  want  to  have 
discontinuous  systems,  are  required  to  be  continuous,  such  as  telecommunications,  data  streams,  and  it 
becomes  an  enormous  problem.  This  is  a  form  of  interoperability  that  affects  the  basic  level  of  all  these 
systems,  the  common  reference  frame  that  they  use.  What  time  do  you  get  out  of  the  system  from  Galileo 
Time  or  GLONASS  Time  or  GPS  Time,  how  do  these  all  combine  into  an  accurate  common  reference 
system  that  everyone  can  use?  I  think  that  is  still  a  good  issue  in  interoperability. 

So  hopefully  we  can  get  some  suggestions  in  our  discussion  of  that  here  today.  Thank  you. 

DETOMA:  Thank  you  very  much,  Ron.  The  next  speaker  is  Dr.  Bill  Klepczynzski  from  the  State 
Department. 

KLEPCZYNSKI:  I  thought  I  was  going  to  be  the  next  to  the  last  speaker,  and  I  thought  would  say  what 
I  was  going  to  say,  so  Ron  started  to  say  what  I  was  going  to  say  and  I  think  Wlodek  will  eventually  talk 
about  more  of  what  I  am  going  to  say,  so  hopefully  I  will  be  very  short. 

But  when  it  comes  to  interoperability,  there  are  on  the  market  already  combined  GPS/GLONASS 
receivers.  They  have  been  around  for  a  long  time.  And  it  is  possible,  from  the  timing  point  of  view,  to  do 
a  solution  for  the  offset,  to  get  different  systems  onto  this  same  time  by  the  individual  receiver. 

However,  one  of  the  shortcomings  of  doing  it  in  this  fashion  is  that  you  need  to  observe  a  lot  more 
satellites  than  you  would  for  your  normal  position  fix,  because  now  you  are  also  solving  for  the  time 
offset  between  the  various  systems.  And  it  is  possible  to  do  that. 

Another  way  to  achieve  timing  interoperability  is  to  have  timing  centers  calculating  and  observing  the 
offset  and  then  transmitting,  say,  via  the  navigation  message,  what  the  offset  is  between  the  different 
navigation  systems.  There  are  some  shortcomings  with  regard  to  that,  and  especially  how  does  one 
coordinate  the  centers  themselves?  And  it  is  not  going  to  be  a  small  minor  thing;  there  is  going  to  be 
some  effort  involved.  And  “some  effort  involved”  means  there  must  be  some  type  of  funding  for  doing  it 
in  this  way  and  this  fashion. 

There  is  another  way  one  can  synchronize  timing  inoperability  between  all  the  systems:  that  they  all  adopt 
the  same  system  time.  And  that  to  me  is  the  ideal  solution;  however,  one  of  the  biggest  shortcomings 
there  is  a  political  situation  as  to  which  time  and  how  one  goes  about  it. 

If  one  tries  to  go  for  the  ideal  solution  of  trying  to  put  all  systems  on  the  same  time,  there  are  some  things 
which  one  has  to  keep  in  mind.  First  of  all,  the  amount  of  effort  that  is  necessary.  And  I  refer  to  how  one 
goes  about  doing  this.  It  is  not  going  to  be  a  trivial  exercise  to  do  this,  to  get  things  done. 

One  has  to  also  keep  in  mind,  the  way  of  reality  to  the  current  situation,  that  GPS  Time  is  around  now; 
people  are  using  it  and,  as  Ron  alluded  to,  many  systems  are  already  synchronizing  their 
telecommunication  systems  to  GPS  Time.  So  if  we  adopt  some  other  type  of  standard  or  some  other 
system,  one  has  to  take  into  consideration  the  effects  on  current  users  around. 

GLONASS  will  probably  use  as  their  time  basis  TAI,  but  I  think  Wlodek  Lewandowski  will  be  saying 
something  about  that  when  he  talks  about  it,  perhaps.  But,  in  some  respects,  TAI  is  really  more  of  a 
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working  timescale  within  the  BIPM  and  it  is  really  not  a  real  timescale  out  in  the  real  world,  where  people 
are  using  it  as  such. 

Ron  also  referred  to  the  UTC  problem  of  trying  to  get  a  timescale  without  leap  seconds,  because  that 
makes  the  navigation  systems  work  much  better,  as  well  as  telecommunication  systems. 

So  if  one  wants  to  try  to  get  a  timing  interoperability  between  the  various  systems,  some  type  of 
compromise  will  be  needed,  and  that  compromise,  I  am  sure,  will  take  several  years  of  discussions 
between  all  the  various  players  to  come  to  some  conclusion.  And,  hopefully,  we  might  keep  a  number  of 
people  employed  for  a  number  of  years  if  that  goes  on  that  way. 

Thank  you. 

DETOMA:  Thank  you,  Bill.  The  next  speaker  is  Dr.  Chris  Hegarty  from  MITRE  Corporation. 

HEGARTY:  Good  afternoon  again.  The  first  chart  I  have  here  has  been  ably  covered  by  Hugo.  I  will 
just  try  to  hit  some  salient  points  that  he  did  not  cover  the  first  go-round. 


C/A 


k 


LI 

(1575.42  MHz) 
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The  top  row  here  is  just  showing  the  GPS  signals  that  we  enjoy  at  present.  As  Hugo  noted,  right  now 
dual-frequency  use  is  confined  to  military  users  and  those  pesky  civilians  that  have  figured  out  how  to 
track  the  Y-code  without  really  knowing  what  it  is.  And,  of  course,  that  [semi-codeless]  technology  is 
quite  widespread  right  now.  But  we  will  all  benefit,  starting  hopefully  next  spring,  when  the  first  II-RM 
satellite  goes  up  and  we  get  a  second  civil  signal;  the  II-RM  satellite  actually  has  the  capability  to  either 
send  on  L2  the  C/A  code  identical  to  what  is  on  L 1 ,  but  the  baseline  is  actually  a  new  improved  signal 
structure  -  and  the  acronym  of  the  day  is  “L2C,”  which  stands  for  “L2  Civilian,”  which  has  a  lot  of 
advanced  features  compared  to  C/A  code,  including  longer  PRN  code.  Actually,  it  has  an  extremely  long 
one  as  one  component.  It  also  has,  as  do  all  the  new  civilian  and  military  components,  a  dataless 
component  which  allows  more  robust  tracking.  From  a  user  perspective,  this  will  hopefully  mean  you  can 
track  signals  in  foliage  and  other  conditions  when  you  couldn’t  otherwise. 

On  the  II-RMs  also  will  come  these  new  military  signals  on  LI  and  L2.  Starting  with  the  first  IIF 
satellite,  which  will  hopefully  go  up  in  calendar  year  2006,  we  expect  to  see  a  whole  new  frequency  with 
a  signal  cleverly  called  “L5,”  same  name  as  the  carrier,  which  has  two  components,  as  Hugo  showed.  On 
L5,  a  quadrature  channel  actually  is  modulated  by  a  PRN  code,  only  without  data,  enabling  this  same  kind 
of  robust  tracking  benefit. 

And,  in  the  future,  sometime  perhaps  in  the  Block  III  timeframe,  one  of  the  components  of  the  US-EU 
agreement  that  was  signed  back  in  June  of  this  year  established  a  baseline  signal  structure  that  GPS  would 
adopt,  as  well  as  the  Galileo  open  service,  which  is  here  called  L1C.  This  is  a  binary  offset  carrier  1,  1 
signal.  It  roughly  looks,  in  the  RF  spectrum,  like  two  copies  of  the  C/A  code,  plus  or  minus  1  MHz  from 
the  carrier. 


GPS  Signals  -  GNSS  Interoperability  Challenges  and  Opportunities 
•Ensuring  Radio  Frequency  (RF)  compatibility 

-  June  2004  US-EU  agreement  for  GPS-Galileo  +  follow-on  working  groups 

-  Ongoing  bilateral  discussions  between  United  States  and  other  nations/organizations  for 
QZSS,  GLONASS,  SBAS,  etc. 

•Enhancing  interoperability 

-  Incorporation  of  system  time  offset  messages  in  navigation  data  for  new  civil/military  signals 

•  Are  there  other  inter-system  messages  that  would  be  useful? 

-  Increasing  commonality  in  messages,  signal  structures,  services 

•  Is  dissimilarity,  in  some  cases,  more  beneficial? 

•Spectrum  protection 


Just  a  few  bullets  to  hopefully  stimulate  discussion  on  interoperability.  As  Edoardo  pointed  out,  one  of 
the  main  tenets  as  in  the  Hippocratic  Oath,  “Thou  shall  do  no  harm,”  or  however  it  is  phrased.  But  this 
was,  of  course,  very  important  to  not  just  the  U.S.,  but  everyone  worldwide,  as  new  civil  and  military 
GPS  signals  and  Galileo  come  online,  want  to  ensure  that  people  continue  to  enjoy  all  capabilities  that 
they  are  enjoying  today  from  GPS.  And,  of  course,  the  Europeans  are  investing  billions  in  Galileo,  and 
they  would  like  to  make  sure  that  they  are  not  going  to  be  interfered  with  by  GPS. 
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So  attached  to  that  US-EU  agreement  in  June  2004,  by  reference,  was  actually  quite  a  lengthy  document 
describing  the  methodology  that  should  be  used  to  ensure  that  the  two  systems  are  RF-compatible.  And 
similar  documents  are  being  used  by  the  U.S.  now  in  bilateral  discussions  with  Japan  for  QZSS,  as  in 
other  bilateral  discussions. 

As  far  as  interoperability  goes,  we  have  heard  a  lot  today  about  the  need  to  provide  time  offsets  between 
Galileo  system  time  and  GPS  time.  That  is  certainly  important;  I  guess,  to  stimulate  discussions  one 
question  would  be,  “is  there  any  other  inter-system  messages  that  might  be  useful?”  This  would  be  a 
good  thing  to  think  about  now,  because  the  signal  specifications  for  the  new  GPS  signals  anyway  are 
quite  far  along.  Back  in  October,  a  document  ICD-GPS-200D  was  approved  by  the  GPS  Joint  Program 
Office,  which  is  the  new  baseline  document,  not  only  for  the  new  L2  civil  signal,  but  also  for  the  L1-L2 
P  (Y)  Code  and  LI -C/A  code.  And  this  document  describes  all  the  messages  that  will  be  used  for  L2C. 

Another  document  was  considered  in  October,  but  not  quite  passed.  It  will  probably  be  adopted  very 
shortly  as  ICD-GPS-705,  which  defines  all  the  gory  details  of  the  L5  signal,  including  the  messages. 
These  satellites  are  going  up  in  the  next  2  years,  so  if  we  do  not  have  these  messages  defined  or  thought 
of,  they  certainly  can  be  added  later  with  the  flexible  messaging  structure  that  we  have.  But  it  will  be 
beneficial  to  be  able  to  define  them  now  so  that  early  user  equipment  can  perhaps  benefit  from  them 
earlier. 

One  other  thing  to  think  about,  as  we  talk  a  lot  about  commonality  between  new  systems  and  messages, 
signal  structure,  and  services,  I  just  pose  a  question  for  the  audience,  which  is  “Is  dissimilarity,  in  some 
cases,  more  beneficial?”  For  instance,  is  it  actually  better  to  have  new  GNSS  signals  on  different 
frequencies  to  help  mitigate  against  interference  (which  you  may  not  expect  to  always  be  on  the  same 
frequency)? 

And  then,  lastly,  a  cheap  plug  for  spectrum  protection,  just  to  keep  everyone  focused  to  some  degree  on 
the  challenges  that  we  all  face  together,  both  in  GPS,  Galileo,  and  other  new  systems  that  are  on  the 
horizon  in  guarding  the  RNSS  spectrum  that  is  needed  to  support  these. 

Thank  you. 

DETOMA:  Thank  you,  Chris.  The  next  speaker  is  Dr.  Hammesfahr  from  DLR. 

HAMMESFAHR:  I  want  to  address  two  different  issues  for  the  interoperability  of  the  Galileo  and  GPS 
systems.  One  of  these  issues  is  timing.  There  will  be  different  reference  timescales  for  Galileo  and  GPS. 
So  there  will  be  an  offset  between  the  GPS  system  time  and  the  Galileo  system  time.  This  offset  is 
abbreviated  as  GGTO.  We  made  a  simulation  about  its  determination  and  influence  on  the  positioning 
accuracy  for  users  of  combined  GPS/Galileo  equipment. 

There  were  several  assumptions  for  these  simulations,  so  what  is  shown  below  is  the  average  case  and  the 
worst  case  for  horizontal  positioning  error  and  for  vertical  positioning  error.  The  first  row  is  for  Galileo 
only.  For  the  Galileo  vertical  positioning  error,  the  simulated  performance  is  to  be  approximately  4 
meters  on  the  average,  and  approximately  6  meters  in  the  worst  case.  If  we  combine  Galileo  with  the 
GPS  system,  and  the  user  is  to  determine  the  difference  in  the  timescales  by  himself,  then  the  user  has  to 
have  at  least  five  satellites  in  visibility.  This  is  the  five-parameter  solution.  And  as  you  see,  there  is  some 
kind  of  improvement  for  the  average  and  also  for  the  worst-case  positioning  error. 
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GGTO  Impact  on  User  Positioning  Accuracy 


average 

worst  case 

GGTO:  GPS-to-Galileo 
Time  Offset 

horizontal  position 
error  (95%) 

vertical  position 
error  (95%) 

horizontal  position 
error  (95%) 

vertical  position 
error  (95%) 

Galileo  only 

2.1  m 

3.7  m 

3.3  m 

6.6  m 

GPS  +  Galileo 

5-parameter  solution 

1.6  m 

2.8  m 

2.8  m 

5.4  m 

GPS  +  Galileo 

4-parameter  solution 
GGTO  error  0  ns 

1.5m 

2.7  m 

2.8  m 

5.3  m 

GPS  +  Galileo 

4-parameter  solution 
GGTO  error  5  ns 

1.6  m 

2.8  m 

2.8  m 

5.5  m 

GPS  +  Galileo 

4-parameter  solution 
GGTO  error  16  ns 

1.7m 

3.3  m 

4.1  m 

10.5  m 
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On  the  other  hand,  the  operators  of  GPS  and  Galileo  could  determine  the  offset  between  the  Galileo 
system  time  and  GPS  system  time,  and  broadcast  it  to  users  who  then  correct  their  measurements  with  it 
(four  parameter  solution).  If  the  broadcast  GGTO  values  were  fault-free,  there  would  be  a  slight 
improvement  with  respect  to  the  user-only  solution.  However,  if  we  consider  an  error  in  the 
determination  of  GGTO  of,  say,  5  nanoseconds  (95%)  -  that  is  the  requirement  in  Galileo  now  -  a  slight 
degradation  will  occur  for  the  average  case;  and  also  for  the  worst  case,  but  it  is  very  slight. 

If  we  do  not  correct  for  GGTO  at  all,  the  total  error  may  be  as  large  as  60  nanoseconds.  Then  we  come 
up  with  a  deteriorated  solution  with  respect  to  the  solution  the  user  would  receive  if  he  determines  GGTO 
himself.  And  the  worst  case  is  even  more  deteriorated  than  the  average  case.  A  similar  situation  will 
occur  if  the  uncertainty  of  the  broadcast  GGTO  value  increases. 

So  resulting  from  these  simulations,  we  think  we  have  to  be  careful  about  determining  on  the  system  level 
the  offset  between  Galileo  Time  and  GPS  Time  if  we  are  not  sure  that  the  residual  errors  will  be  small 
enough. 

The  second  issue  I  want  to  address  is  certification.  Let’s  relate  it  to  safety-critical  applications.  For 
example,  civil  aviation.  For  these  applications,  there  are  authorities  requiring  certification  of  the 
navigation  services.  And  the  certification  procedure  for  Galileo  as  it  is  being  planned  now.  This  is  not 
yet  fixed,  and  will  be  done  in  two  stages.  So  there  will  be  certification  on  the  system  level.  Related  to  the 
Galileo  system,  there  are  plans  to  have  a  Safety  Case,  that  is,  to  provide  visibility  to  the  users  about  the 
development  and  operation  of  the  system. 
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Related  to  the  augmentation  systems  like  WAAS,  EGNOS,  MSAS,  and  so  on,  there  are  also  plans  to  have 
a  Safety  Case.  However,  if  you  want  to  combine  these  services,  then  with  the  GPS,  we  also  need  some 
commitments  from  the  GPS  system.  So  we  need  a  kind  of  Safety  Case  or  a  kind  of  a  validation  file  to  be 
sure  that  this  system  is  operated  to  specific  standards. 

The  system-level  certification  is  done  for  a  generic  environment  and  a  generic  receiver.  However,  the 
system  combination  occurs  on  the  user  level.  Users  receive  signals  from  different  systems  in  an 
application-specific  environment  and  with  an  application-specific  receiver.  Then  there  shall  be  an 
additional  certification  related  to  individual  applications.  So  this  user  certification  has  to  take  into 
account  the  safety  requirements  and  also  the  requirements  for  the  performance  of  individual  applications. 
For  example,  for  civil  aviation,  there  are  different  phases  of  flight  and  there  will  be  different  sets  of 
requirements. 

So  concerning  safety-critical  applications,  we  have  to  consider  those  different  levels  of  certification  in 
order  to  have  these  systems  interoperable. 

DETOMA:  Thank  you  very  much,  Jens.  The  next  speaker  is  Dr.  Koshelyaevsky  from  VNIIFTRI, 
Russia. 

KOSHELYAEVSKY:  Let  me  briefly  introduce  myself.  My  position  in  GLONASS  is  limited.  I  am 
from  the  National  Service  for  Time  and  Frequency.  So  I  am  responsible  only  for  the  time  aspects  of  this 
problem. 
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As  special  fulfillment  of  the  requirements  of  this  system  interoperability,  we  expect  to  generate  the 
national  timescale  UTC  (RU),  which  will  be  starting  30  December  of  this  year.  And  we  expect  that  we 
may  steer  to  UTC  within  about  20  nanoseconds.  So  it  will  ensure  possible  timeframe  for  GLONASS. 

Regarding  GLONASS  updates,  I  will  be  able  to  give  you  some  information  coming  from  Russia.  The 
new  generation  of  GLONASS  satellites  will  have  a  much  longer  life.  It  is  expected  that  it  will  be  about  7 
years  and  in  the  next  generation,  even  more.  Then  it  is  expected  that,  up  to  2008,  the  constellation  will  be 
about  18  to  24  satellites. 

GLONASS  people  are  strongly  interested  in  our  secondary  time  laboratories,  which  are  widespread  over 
the  whole  territory  of  Russia  from  Moscow  to  the  Far  Eastern  region.  And  they  would  like  to  use  it  in  a 
controlled  segment  of  GLONASS  as  a  source  of  precise  ephemeris  and  timing  information. 

To  my  understanding,  the  GLONASS  interoperability  may  be  based  on  well-known  CCTF 
recommendations,  which  require  as  close  as  possible  time  synchronization  of  system  times.  In  other 
words,  when  you  transform  geodetic  system  to  another,  there  will  be  no  trouble  transforming  this  system. 

I  will  further  apprise  you  and  the  International  timing  community  to  GLONASS  when  I  come  back  after 
discussing  this  problem  with  my  colleagues. 

Thank  you. 

DETOMA:  Thank  you  very  much.  The  next  speaker  is  Wlodek  Lewandowski  from  BIPM. 

LEWANDOWSKI:  Good  afternoon.  I  would  like  to  turn  to  the  subject  of  reference  timescales  for  the 
various  GNSS  systems  that  are  in  place  now,  or  that  we  will  have  in  the  near  future,  and  will  speak  about 
differences  of  the  order  of  seconds,  not  nanoseconds. 

In  general,  the  GNSS  systems  are  referred  to  the  official  international  timescale  UTC.  However,  there  is 
some  confusion  about  the  use  of  different  terms  and  timescales.  I  show  below  a  plot  which  illustrates 
how  UTC  has  evolved  from  the  beginning  of  the  1970s,  when  this  system  was  introduced.  These  steps 
are  leap  seconds.  Currently,  we  have  a  32  s  difference  between  TAI  and  UTC.  There  have  not  been  any 
leap  seconds  in  the  last  few  years. 

GPS  was  introduced  in  1981,  and  GPS  time  was  set  -  I  don’t  remember  the  date  -  to  be  zero  with  respect 
to  UTC.  It  seemed  logical  for  GPS  be  referenced  to  the  official  reference  timescale.  But  since  then,  in 
agreement  with  the  definition  of  this  reference  timescale  for  GPS,  which  is  a  continuous  timescale,  GPS 
has  not  applied  any  leap  seconds.  UTC,  on  the  other  hand,  has  leap  seconds  here. 

Now,  let’s  turn  to  another  GNSS:  GLONASS,  which  is  not  yet  operational.  GLONASS  is  also  using 
UTC  for  its  reference  time,  but  it  is  applying  leap  seconds.  This  poses  a  technical  problem;  in  the  past, 
the  GLONASS  constellation  encountered  major  problems  during  the  introduction  of  leap  seconds.  In 
fact,  it  was  probably  this  problem  that  triggered  the  discussion  about  the  future  of  leap  seconds. 

Since  GLONASS  improved  the  introduction  of  leap  seconds,  have  been  no  major  problems  on  the 
GLONASS  constellation.  GLONASS,  we  must  say,  is  the  closest  to  following  international 
recommendation,  because  it  is  following,  for  its  reference  timescale,  the  international  reference  timescale 
UTC. 
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bipm  [TAI  -  Time  scale (/)] 


Year 


What  about  the  new  system  Galileo?  Galileo  has  chosen  to  use  TAI  as  a  reference.  At  first  look,  this 
seems  very  logical,  because  TAI  does  not  have  leap  seconds.  Having  seen  the  problems  experienced  by 
GLONASS,  Galileo  operators  do  not  want  to  worry  about  the  introduction  of  leap  seconds.  The  issue  is 
that  if  Galileo  is  officially  referring  to  TAI  and  is  saying  that  it  is  Galileo  time,  Galileo  will  be 
broadcasting  TAI.  But  there  are  strong  regulations  for  broadcasting  time  signals,  and  TAI  is  not  the 
recommended  timescale  for  broadcasting. 

Also,  from  the  BIPM  point  of  view,  TAI  is  a  scientific  frequency  reference  for  the  final  product,  which  is 
UTC.  It  is  true  that  it  does  not  have  leap  seconds,  but  that  does  not  mean  that  it  is  automatically  a 
timescale  for  users.  There  are  some  strong  currents  of  opinion  to  use  it  as  an  alternate  timescale,  but  we 
do  not  have  an  official  recommendation  for  that.  And  this  would  lead  to  a  situation  where  we  have  two 
official  timescales:  UTC  and  TAI.  But,  in  my  opinion,  having  two  official  timescales,  differing  by  tenths 
of  seconds,  may  lead  to  problems,  both  now  and  in  the  future.  So  I  would  like  to  ask  your  opinion  about 
this  issue,  which  I  think  is  a  very  serious  one  and  an  important  part  of  the  discussion  about  the  future  of 
leap  seconds. 

DETOMA:  Thank  you  very  much.  Our  next  speaker  is  Dennis  McCarthy  from  the  U.S.  Naval 
Observatory. 

MCCARTHY:  I  have  taken  a  slightly  different  approach  with  respect  to  the  rest  of  the  speakers.  This 
slide  outlines  some  things  which  I  think  need  to  be  considered,  or  have  been  considered. 
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Things  to  Consider 


Time 

Being  discussed 

Terrestrial  Reference  Frame 

WGS  84  =  ITRF  at  the  few  centimeter  level 


First  of  all,  we  have  heard  just  about  everyone  on  this  panel  speak  about  time  being  the  issue.  And  no 
doubt  that  time  is  an  issue,  and  it  is  now  the  time,  I  believe,  to  try  to  resolve  that  issue.  Making  no 
decision  on  the  possibility  of  a  navigational  time  scale  different  from  UTC  is,  in  fact,  making  a  decision. 
Software  is  being  written  as  we  speak  for  navigational  systems  of  the  future,  and  right  now  we  constantly 
hear  about  the  issues  of  making  any  changes  in  the  legacy  issues.  If  we  go  back  and  reconfigure  software, 
that  has  already  been  in  the  books  for  the  last  30  years,  it  is  a  huge  expense.  We  are  doing  that  right  now 
to  the  future  generations.  So  generations  from  now  will  be  thanking  us  for  the  fact  that  we  did  or  did  not 
make  a  decision  at  this  point  regarding  a  timescale.  And  at  the  rate  that  we  are  progressing,  I  guess,  they 
will  not  be  thanking  us  a  lot. 

So  this  decision  needs  to  be  made,  and  made  rather  soon  as  to  what  we  are  going  to  do,  and  if  we  are 
going  to  keep  these  leap  seconds  or  if  we  are  going  to  adopt  some  kind  of  navigational  timescale  that  is 
common  to  all  navigational  systems. 

So  we  have  heard  about  time,  and  we  have  heard  about  the  terrestrial  reference  frame  as  issues  for 
interoperability.  I  think  that  we  are  all  pretty  much  convinced  now  that  the  WGS  84  is  essentially  the 
ITRF  and  that  we  can  dismiss  the  concern  about  the  terrestrial  reference  frame  at  the  few- centimeter  level 
and  go  on. 


But  ... 

Terrestrial  to  Inertial  Transformation? 
Gravity  Field? 

Earth  Orientation? 

Models? 

Tides 

Troposphere 

Ionosphere 


But  there  are  other  things  that  have  yet  to  be  considered,  I  submit,  for  concerns  in  navigational  system 
interoperability.  These  are  things  that  I  show  there  as  the  terrestrial-to-inertial  transformations.  The 
International  Astronomical  Union  in  the  year  2000  passed  some  recommendations  regarding  the  future 
paradigm  to  be  used  to  transform  between  the  international  celestial  and  the  international  terrestrial 
reference  frames. 
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These  call  for  essentially  a  total  revamping  of  the  way  that  things  have  been  done  in  this  area.  I  am  sure 
that  the  GPS  folks  will  not  want  to  change  from  the  system  that  has  been  built  in  for  the  last  30  years; 
however,  I  suspect  that  those  designing  new  systems  will  want  to  take  advantage  of  the  most  recent  IAU 
recommendations.  It  is  not  that  there  is  a  lot  of  difference  between  them,  but  there  are  significant 
differences.  These  things  need  to  be  at  least  discussed,  and  the  differences  between  them  established. 
The  gravity  fields,  the  Earth  orientation;  how  do  we  handle  Earth  orientation  parameters?  We  know  how 
we  do  it  in  the  GPS  system;  they  are  built  into  this  system  to  force  the  relationship  between  the  terrestrial 
and  the  celestial  system.  Is  that  going  to  be  done  the  same  way  in  other  navigational  systems? 

Are  we  going  to  use  the  same  models  for  tides?  What  models  to  use  for  tides?  What  models  are  we 
going  to  use  for  the  troposphere?  What  models  are  we  going  to  use  for  the  ionosphere?  And  this 
reference-frame  issue  is  truly  a  four-dimensional  issue.  We  also  have  to  worry  about  the  relativistic 
issues,  and  how  one  handles  the  relativistic  concerns  in  analyses  of  orbits.  We  have  clocks  flying  at 
altitude;  we  have  got  clocks  flying  on  the  surface  of  the  earth.  How  do  we  relate  those  and  put  those  into 
a  common-time  system? 

And  these  things,  while  small  in  comparison  to  seconds,  as  we  have  heard  about,  are  nevertheless  going  to 
be  there  and  need  to  be  discussed  at  this  point.  Again,  failure  to  make  decisions  regarding  these  standards 
and  these  conventions  is,  in  fact,  making  a  decision. 

DETOMA:  Thank  you  very  much,  Dr.  McCarthy.  Our  next  speaker  is  Dr.  Powell  from  the  Aerospace 
Corporation. 

POWELL:  Hi,  I  am  new  to  the  world  of  interoperability,  but  my  most  recent  experience  is  with  the  GPS 
JPO  in  the  field  of  user  equipment.  So  a  couple  of  the  issues  that  I  would  raise  from  a  user-equipment 
perspective,  or  an  applications  perspective,  are  as  follows.  One  has  to  do  with  the  spacecraft  applications 
of  GPS,  in  particular,  high  altitudes  of  geosynchronous  spacecraft.  And  I  am  interested  in  how  the 
Galileo  signals  will  or  will  not  contribute  to  that,  and  how  high-altitude  spacecraft  navigation  will  work  in 
a  combined  GPS/Galileo  era. 

The  other  issue,  I  guess,  going  forward  as  far  as  clocks  is  the  industrial  base  and  how  the  industrial  base 
for  clock  manufacturers,  both  for  spacebome  and  terrestrial  clocks,  will  develop  during  a  GPS/Galileo 
era. 

And  also,  finally,  how  will  integrity  work  for  combined  GPS/Galileo  systems.  I  would  also  be  interested 
in  that. 

That  is  all  I  have. 

DETOMA:  I  thank  all  the  speakers,  and  I  think  we  have  many  questions  and  issues  on  the  table.  And 
possibly  more  when  you  start  asking  questions.  I  would  ask  if  anyone  would  start  the  discussion  by 
asking  the  first  question. 

MARC  WEISS  (National  Institute  of  Standards  and  Technology):  I  have  noticed  that  the  way  the 

GPS  time  minus  the  Galileo  is  going  to  be  estimated  is  by  measurement  at  the  Galileo  station.  I  have  also 
noticed  the  importance  of  it  getting  it  right.  And  I  am  wondering  that  why  not  do,  say,  Two-Way  between 
Shriever  Air  Force  Base,  where  GPS  Time  is  known,  and  the  source  of  Galileo  Time,  where  the  Master 
Clock  is,  and  actually  measure  directly  instead  of  through  the  satellite  system? 

HAMMESFAHR:  I  fully  agree  with  you.  However,  the  prerequisite  for  this  procedure  should  that  there 
will  be  direct  access  to  GPS  Master  Clock  or  Master  Time  and  to  Galileo  Master  Clock/Master  Time. 
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And  then  to  have  a  direct  link  between  these  two  facilities  and  to  determine  the  difference  in  the  timing 
scales. 

So,  presently,  we  are  not  sure  if  this  direct  access  will  be  guaranteed.  But  if  so,  I  think  this  would  be  the 
best  means,  yes. 

BEARD:  I  think  part  of  the  problem  is  with  GPS,  and  I  am  certainly  not  the  foremost  expert  on  this;  it  is 
their  use  of  the  Composite  Clock  and  how  will  time  will  permit  realization  when  comparing  them.  I  think 
that  is  a  fundamental  issue. 

If  I  could  make  a  slight  addition  to  the  leap  second  question,  if  you  don’t  mind.  Part  of  the  issue  of  the 
leap  second  question  that  seems  to  be  reoccurring  is  that  most  of  the  projections  by  people  looking  at 
current  geophysics  is  that  the  necessity  for  leap  seconds  will  be  increasing.  So  there  could  be  the 
possibility  of  having  multiple  leap  seconds  a  year. 

So  it  is  not  only  adding  the  leap  second  and  introducing  that,  but  having  the  multiplicity  of  leap  seconds 
further  complicates  the  issue. 

Something  else  to  think  about. 

DEMETRIOS  MATSAKIS  (U.S.  Naval  Observatory):  Just  wanted  to  clear  up  a  technical  issue,  and 
you  sort  of  said  that,  Ron.  Time  is  not  known  at  Shriever  Air  Force  Base;  the  time  for  GPS  is  set  right 
here  in  Washington,  D.C.,  at  the  Naval  Observatory.  That  is  a  time  reference.  The  Composite  Clock 
discussion  could  be  taken  somewhere  else;  this  is  not  the  time  to  get  into  it.  That  algorithm  is  a  whole 
complicated  subject;  I  would  not  say  that  anything  was  wrong  with  it.  Whatever  it  does,  it  all  gets 
washed  away  when  it  gets  reference  to  the  USNO  here. 

So,  in  fact,  there  are  discussions  about  Two-Way;  they  involve  taking  time  from  the  USNO  in 
Washington,  D.C.,  to  the  Galileo  reference. 

KLEPCZYNSKI:  In  regard  to  that,  there  still  is  the  question,  as  Ron  mentioned  and  as  Demetrios 
alluded  to,  GPS  time  is  really  an  algorithm  output.  And  even  though  we  measure  the  offset,  say,  at 
USNO,  there  is  still  always  a  delay  between  the  time  that  the  offset  is  known  and  when  it  gets  uploaded  to 
the  satellite;  so  this  would  have  to  be  taken  into  the  loop  also,  to  try  to  enclose  and  tighten  the  difference 
between  the  projected  offset  between,  say,  GPS  and  Galileo  time. 

MATSAKIS:  That  offset  is  about  1  nanosecond  right  now,  and  I  showed  a  plot  of  it  in  my  talk.  And  it  is 
the  standard  plot  I  give  in  all  my  summary  things. 

Maybe  it  is  not  important  -  and  I  should  have  said  this  during  the  scientific  sessions  -  the  GGTO  talk  had 
a  spec  of  5  nanoseconds  for  the  difference,  and  it  was  considered  that  that  was  hard  to  do.  In  my  opinion, 
several  items  in  that  error  budget  were  higher  than  they  had  to  be,  and  it  might  be  easier  to  achieve  their 
5-nanosecond  spec,  if  that  is  what  they  want.  It  is  good  that  they  are  conservative,  though,  and  that  means 
that  they  will  really  do  it  right. 

BEARD:  Certainly  the  Naval  Observatory’s  time  reference  is  the  time  reference  for  GPS.  However,  the 
practical  operating  time  for  GPS  is  determined  by  the  Composite  Clock.  And  I  would  think  it  would  be 
more  accurate  if  you  were  to  reference  a  clock  that  is  included  in  the  composite  clock  and  look  at  that 
difference  as  compared  to  the  difference  with  the  reference  of  the  Galileo  system,  rather  than  one  which  is 
not  included  in  the  Composite  Clock. 
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HAMMESFAHR:  One  remark.  I  think  what  the  user  wants  to  know  is  to  know  the  offset  of  each 
individual  satellite  clock  with  reference  to  some  reference  system  time.  So  if  you  could  imagine  one 
monitoring  system  monitoring  all  GPS  satellites,  monitoring  all  Galileo  satellites,  maybe  monitoring  all 
GLONASS  satellites  at  the  same  time,  using  one  orbit  computation,  including  determination  of  individual 
satellite  clock  times,  and  then,  to  provide  the  information  for  each  individual  satellite  clock,  I  think  this 
would  be  the  most  adequate  information  the  system  could  provide  to  the  users. 

BEARD:  I  think  that  is  the  value  of  the  way  the  Composite  Clock  is  implemented,  in  that  it  determines 
the  offset  for  each  individual  satellite  clock.  And  that  is  brought  on  to  a  common  synchronized  time.  I 
think  that  is  the  value  of  the  way  the  composite  clock  is  implemented  and  it  determines  the  offset  from  the 
three-clock  satellite  for  each  individual  one. 

HAMMESFAHR:  Yes,  but  what  we  need  is  a  GPS/Galileo  Composite  Clock,  not  a  GPS  Composite  and 
a  Galileo  Composite  Clock. 

DETOMA:  The  problem  is  that  right  now  we  are  facing  a  situation  in  which  each  system  will  maintain 
its  independence,  even  though  they  are  interoperable.  Certainly,  if  you  put  all  the  solutions  in  one  single, 
bigger  system,  you  get  an  enormous  advantage.  But  possibly  this  is  not  really  the  case  right  now. 

MATSAKIS:  In  fact,  I  think  you  are  right.  And  that  is  why  there  is  a  whole  growth  of  real-time  systems 
that  give  all  the  numbers  like  that,  all  the  corrections  that  users,  if  they  want  to  spend  money,  can  buy 
from  the  real-time  systems. 

So  it  is  happening,  with  or  without  the  top  people  doing  it,  by  these  other  groups. 

BEARD:  I  think  the  closest  to  it  right  now  currently  is  the  IGS.  It  is  already  doing  that. 

KLEPCZYNSKI:  Just  some  comments.  Just  to  keep  in  mind  and  in  perspective  of  what  we  are  trying 
to  discuss  -  because  Jens  referred  to  this  in  regard  to  what  the  user  really  needs.  The  user  out  in  the  field 
that  is  navigating  would  like  to  have  a  mixture  of  satellites  to  choose  from  to  get  his  position  fixed, 
whether  it  be  Galileo  or  GPS  or  GLONASS,  because  that  is  what  gives  you  a  more  robust  navigational 
fix. 

So  the  goal  that  has  to  be  kept  in  mind  is  how  you  can  make  it  easier  for  the  user  of  this  receiver  to 
navigate  into  a  multiple  fix  of  satellites  to  avoid  urban  blockage  and  cities  and  by  using  different 
satellites.  And  that  is  the  main  ultimate  goal  that  we  are  looking  for. 

BOB  NELSON  (Satellite  Engineering  Research  Corporation):  I  would  just  like  to  offer  a  couple  of 
comments  to  elaborate  on  some  of  the  remarks  that  some  the  speakers  have  made  and  then  pose  a  general 
type  of  question. 

With  respect  to  the  leap  second  issue,  Wlodek  showed  the  trend  of  UTC  since  it  was  initiated  in  1972. 
The  fact  is  that  we  are  currently  in  a  kind  of  decade  fluctuation  in  that  we  have  not  had  leap  seconds  for 
several  years.  But  that  trend  is  going  to  continue;  in  fact,  the  trend  has  continued  for  literally  millions  of 
years.  There  is  evidence  through  coral  fossils  and  other  types  of  evidence  that  show  that  the  length  of  the 
day  is  increasing  at  a  steady  rate  -  which  is  extended  over  geological  history. 

The  fact  that  we  have  not  had  a  leap  second  for  a  few  years  implies  that  we  will  have  multiple  leap 
seconds  in  the  very  near  future,  if  necessary,  to  keep  the  definition  of  UTC  as  it  is  now.  Not  simply 
because  the  length  of  the  day  is  increasing,  but  simply  to  make  up  for  the  leap  seconds  we  haven’t  had  in 
the  last  few  years. 
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So  I  would  predict  with  the  next  10  years,  if  UTC  is  not  redefined,  the  IERS  will  mandate  that  we  have 
maybe  three  or  possibly  four  leap  seconds  in  a  single  year,  maybe.  Or  at  least  several  over  several  years. 
So  this  is  a  very  real  issue  in  the  near  future,  not  in  the  long  term. 

Another  thing  that  Dennis  elaborated  on,  and  also  I  commented  it  on  before,  is  a  need  for  a  model. 
Amongst  the  speakers,  I  am  hearing  a  need  for  statistical  time  comparisons  among  clocks  on  satellites  and 
GPS  Time  and  Galileo  Time.  But,  really,  we  need  to  consider  the  distinction  between  proper  time  and 
coordinate  time.  And  they  are  different  for  the  two  systems.  Not  only  is  there  a  secular  difference,  but 
there  is  a  variable  difference  from  satellite  to  satellite.  And  I  would  like  to  emphasize  again  the  need  to 
consider  that  variable  difference.  We  do  not  have  a  Newtonian-like  time;  we  have  a  relativistic  time  in 
the  frame  of  reference  of  the  rotating  earth. 

But  the  point  that  I  would  like  to  emphasize  and  pose  a  question  to  is,  I  believe  we  are  in  a  unique  point  in 
the  history  of  time,  a  confluence  of  events:  the  need  to  consider  the  possibility  of  redefining  UTC,  and 
the  existence  of  many  components  of  the  GNSS,  GPS,  Galileo,  GLONASS,  and  other  possible  systems  in 
the  future. 

It  will  be  desirable,  I  think  many  people  agree,  to  converge  toward  a  common  timescale  in  the  future, 
which  poses  many  problems,  and  Bill  hinted  on  some  of  them.  So  the  question  I  would  like  to  ask  is: 
Are  there  any  people  on  the  panel  or  in  the  audience  who  would  care  to  suggest  how  this  goal  of 
converging  toward  a  common  international  scale  of  time,  used  by  both  the  civilian  community  and  by  the 
GNSS,  can  be  possibly  attained? 

FRUEHAUF:  As  a  GPS  applications  kind  of  person,  I  view  the  timescale  differences  between  GPS  and 
Galileo  to  be  the  least  of  the  problems  that  will  be  encountered.  In  other  words,  any  properly  designed 
GPS  receiver  should  be  able  to  make  a  timescale  adjustment  based  on  the  geodetic  model  used  for  that 
satellite  system.  For  example,  for  GPS  satellites,  it  should  make  the  PVT  calculations  using  the  GPS 
geodetic  baseline.  For  Galileo  satellites  in  view  of  the  same  receiver,  it  should  calculate  PVT  on  the  basis 
of  the  Galileo  geodetics  and  then  provides  a  final  PVT  solution  based  on  all  the  satellites  in  view  properly 
corrected  and  voted. 

BEARD:  I  believe  the  answer  is  simple.  The  common  international  time  today  is  UTC  as  is 
recommended  by  the  ITU-R.  That  is  the  common  timescale  used  for  telecommunications  purposes  and  is 
coordinated  internationally  by  the  BIPM. 

McCARTHY:  Yes,  I  just  have  a  few  comments  to  make  on  the  formation  of  a  common  timescale. 

I  think  it  is  clear  that  Universal  Time  is  considered  to  be  the  common  timescale  internationally.  It  is  the 
reason  the  International  Telecommunications  Union  Resolution  was  implemented  in  the  definition  and  is 
why  the  International  Telecommunications  Union  is  reconsidering  it. 

However,  I  think  it  is  necessary  to  distinguish  between  a  navigational  timescale  and  a  timescale.  The 
navigational  timescale  is  part  and  parcel  to  the  navigation  solution  of  these  navigational  systems.  And 
that  situation  is  reflected  in  the  fact  that  both  Galileo  and  GPS  provide  their  own  system  time,  a 
navigational  timescale  for  use  in  navigation,  as  well  as  a  timescale  for  use  in  timing  applications.  And  I 
think  it  is  also  clear  that  the  proposed  Galileo  and  GPS,  that  one  of  the  products  will  in  fact  be  the  time, 
not  it  is  built  as  a  navigational  system  does  -  we  found  out  that  GPS  Time  is  probably  more  an  important 
product  than  the  actual  navigation  solutions.  There  are  more  users  of  the  time  than  there  are  the 
navigation.  So  we  have  to  consider  that. 

In  building  a  common  timescale  that  reunites  the  navigational  timescale,  the  timescale  for  time  and 
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frequency  purposes,  the  issues  are  not  difficult  technically.  It  is  clear  that  we  have  timescales  that  could 
mesh  that  could  serve  the  purpose.  Coordinated  Universal  Time  can  probably  serve  that  purpose. 

The  issues  are  political  and  emotional,  and  not  technical.  So  that  this  is  why  Bob’s  suggestion  that  the 
common  timescale  is  called  for,  I  think,  is  quite  appropriate.  But  the  tough  part  is  cracking  the  politics 
and  the  turf  of  the  various  systems. 

HEGARTY :  I  just  had  a  thought  earlier  that  I  wanted  to  make  sure  I  did  not  forget. 

Earlier,  my  colleague  was  talking  about  the  alternate  method  for  determining  the  time  offset  between  GPS 
and  Galileo,  which  is  actually  to  let  the  user  equipment  compute  that  as  part  of  the  navigation  solution. 
The  drawback,  as  was  indicated,  was  the  cost  of  an  additional  measurement. 

I  would  just  like  to  point  out  that  if  you  have  a  sequence  of  measurements,  given  the  fact  that  this  bias  is 
not  expected  to  change  very  rapidly,  nor  are  the  receiver  internal  biases,  there  is  certainly  a  practical 
solution;  when  you  have  five  satellites  in  view,  you  fix  it,  and  perhaps  even  average  over  the  whole  time; 
you  have  those  extra  measurements  available.  And  if  you  are  in  an  urban  canyon  situation,  you  can  freeze 
it  for  quite  some  time.  As  I  understand,  your  specification  of  28  nanoseconds,  whatever  it  was,  over  10 
days,  I  think  that  would  work  quite  well. 

LEWANDOWSKI:  It  is  true  that  GPS  Time,  GLONASS  Time,  and  Galileo  Time  are  internal  timescales 
for  each  of  these  systems.  They  play  a  technical  role  as  reference  time  in  the  process  of  navigation 
solution.  So  in  a  theoretical  world,  they  can  be  completely  different  from  international  timing;  the  only 
requirement  would  be  their  stability. 

However,  in  the  real  world,  what  is  happening  with  GPS  time?  Because  of  the  lack  of  leap  seconds  in 
GPS  Time,  there  are  several  communities,  who  instead  of  using  UTC,  also  broadcast  by  GPS,  are  using 
GPS  Time  as  the  reference  for  their  applications. 

So  we  are  now  aware  of  this  problem  of  leap  seconds.  Because  leap  seconds  pose  a  problem,  there  are 
users  who  forget  that  GPS  Time  is  meant  to  be  an  internal  timescale  of  GPS,  and  adopt  it  as  the  reference 
timescale  for  their  own  applications.  This  is  a  problem. 

Now  with  the  imminent  arrival  of  Galileo,  and  its  consideration  to  use  TAI,  they  are  choosing  a  symbolic 
timescale.  In  my  opinion,  this  is  misleading,  because  this  fairly  technical  reference  timescale  becomes 
something  much  more,  because  it  is  referring  to  International  Atomic  Time. 

This  leads  to  confusion,  because  many  users  of  them  are  not  aware  of  all  the  issues  of  leap  seconds  and 
how  UTC  is  manufactured  and  so  on.  Particularly  if  they  know  that  this  timescale  is  referring  to 
International  Atomic  Time,  it  is  not  immediately  clear  that  this  is  different  from  legal  time  worldwide. 

So  the  situation  is  that  because  of  leap  seconds  and  the  problems  they  are  causing,  along  with  a  number  of 
other  issues,  people  start  to  use  internal  timescales  of  navigation  systems  instead  of  the  official  reference 
timescale  UTC. 

The  timing  metrology  community  contributing  to  UTC  is  the  first  guilty  party,  because,  instead  of  UTC, 
they  chose  GPS  Time  as  a  reference  time  for  common  view.  I  don’t  know  when  or  why  this  choice  was 
made.  But  all  GPS  receivers,  professional  receivers  for  timing,  refer  to  GPS  Time.  Although  it  is 
possible  to  switch  them  to  choose  UTC  for  common  view,  GPS  Time  was  chosen  as  reference.  So  this  is 
the  point:  internal  reference  timescales  of  navigation  systems  are  used,  and  very  widely.  We  should  not 
neglect  this  phenomenon. 
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DETOMA:  Thank  you.  Any  other  comment  on  this  same  subject? 

FRUEHAUF:  As  an  applications  kind  of  person.  I’m  thinking  of  the  timescale  to  be  the  least  problem. 
In  other  words,  any  GPS  receiver  can  be  set  to  GPS  Time  or  UTC.  To  me,  every  time  I  receive  a  GO 
code  and  I  find  out  what  the  satellite  is,  I  could  add  or  subtract  whatever  leap  seconds  you  want  in  order 
to  get  the  timescale  I  want  to  work  on.  It  could  even  be  user-defined.  In  my  opinion,  the  bigger  problem 
is  the  actual  clock  offsets.  In  GPS,  of  course,  going  with  crosslinks  will  go  a  long  way  towards  real-time 
updates  of  satellites  and  I  guess  that  posed  a  question  to  the  Galileo  community;  they  have  no  plans  for 
crosslinks.  To  me,  this  is  where  I  would  worry.  I’m  not  worried  about  the  fact  that  one  is  using  TAI  and 
the  other  is  using  UTC.  I  can  easily  do  that  with  software  once  I  have  received  the  satellite  GO  code. 

DETOMA:  Thank  you.  Any  other  questions  from  the  audience?  If  not,  I  would  like  to  raise  a  question 
myself. 

One  of  the  things  that  we  were  discussing  with  Galileo  is  the  possibility  to  broadcast  via  Galileo  the 
integrity  of  GPS,  since  basically  Galileo  will  act  as  an  augmentation  system  for  GPS,  at  least  for  integrity 
in  this  case.  How  do  you  feel  about  this  possibility? 

HEGARTY:  I  was  just  over  to  Zurich  last  week  at  a  Euro-K  meeting  where  there  were  some  Galileo 
folks  there.  When  this  topic  came,  I  believe  the  answer  was  that  they  do  have  a  data  rate  limitation  even 
using  125  bytes  per  second  on  both  the  LI  signal  as  well  as  on  E5b,  and  they  don’t  plan,  as  far  as  I  know, 
to  broadcast  GPS  corrections  because  they  . . . 

DETOMA:  No,  I  am  not  talking  about  corrections. 

HEGARTY:  ...  they  do  not  plan  to  provide  integrity  data  because  of  that  limitation  as  well  as  some 
certification  issues  that  they  do  not  have  the  insight  to  the  reliability,  robustness,  and  other  things  of  the 
GPS  satellite  to  do  so. 

DETOMA:  Any  other  questions? 

MATSAKIS:  I  would  like  to  follow  on  Chris’s  comment  that  maybe  we  do  not  have  to  worry  about 
interoperability,  because  we  can  measure  the  GGTO  at  one  time. 

I  know  that  when  E9 1 1  comes  out,  I  am  going  to  buy  a  cell  phone  for  my  daughter,  and  I  am  not  going  to 
care  how  much  it  costs,  and  she  often  has  it  turned  off,  so  there  can  be  situations  where  she  just  whips  it 
on  in  a  building,  and  we  are  going  to  want  every  satellite  there  and  know  the  offsets  too.  Do  you  agree 
that  are  certain  scenarios  where  that  works? 

HEGARTY:  Well,  I  guess,  thinking  through  that  particular  scenario,  so  if  it  does  come  on  -  and  there  is 
a  broadcast  one,  but  it  is  not  as  accurate  as  measuring  it  yourself,  so  when  she  dials  E91 1,  she  is  within  4 
meters  instead  of  2.  It  does  not  seem  like  a  severe  limitation  where  you  do  take  advantage  of  that  fifth 
measurement  when  it  is  available.  The  ideal  way  would  actually  be  able  to  use  a  Kalman  filter  where  you 
look  at  the  covariance,  and  when  you  see  the  covariance  of  your  estimate  that  you  have  averaged,  as  long 
as  you  have  five  satellites  visible,  start  to  deteriorate  when  you  are  down  to  four;  when  that  exceeds  the 
achievable  variance  of  the  broadcast  parameter,  you  switch  from  one  to  the  other  and  that  sort  of  thing. 

MATSAKIS:  There  is  no  time  for  a  Kalman  filter.  There  is  an  emergency  situation;  you  turn  it  on,  you 
want  it  to  go. 

HEGARTY:  Yes,  in  that  situation  -  but,  my  personal  preference  would  be  to  use  it  both  ways,  to 
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actually  provide  it  for  people  that  care  not  to  do  extra  work.  But  smart  receiver  vendors,  whether  you 
want  them  to  or  not,  I  am  sure  are  going  to  estimate  it  if  they  do  a  better  job  than  the  broadcast  parameter. 
And  I  frankly  think  you  can  in  most  situations. 

BEARD:  I  think  she  is  in  trouble  if  she  is  in  a  building. 

DETOMA:  Any  other  questions?  If  not,  I  will  close  the  session  here.  Thank  you. 
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